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i 1 Abstract 

h-1 : 

p , A sup-interpretation is a tool which provides an upper bound on 

^ ■ the size of a value computed by some symbol of a program. Sup- 

, interpretations have shown their interest to deal with the complexity 

of first order functional programs. For instance, they allow to charac- 
I \ terize all the functions bitwise computable in Alogtime. This paper is 

■ an attempt to adapt the framework of sup-interpretations to a fragment 

C*") ' of oriented-object programs, including distinct encodings of numbers 

through the use of constructor symbols, loop and while constructs and 
non recursive methods with side effects. We give a criterion, called 
brotherly criterion, which ensures that each brotherly program com- 
putes objects whose size is polynomially bounded by the inputs sizes. 

t> : 

1 Introduction 

> ■ 

^ . A sup-interpretation is a tool introduced in [13] in order to deal with the 

Implicit Computational Complexity of first order functional programs. Ba- 
sically, the sup-interpretation of a first order functional program provides 
upper bounds on the size of any value computed by some function symbols of 
the program. The notion of sup-interpretation is a descendant of the notion 
of quasi-interpretation. See [5] for a survey on quasi-interpretations. It has 
been demonstrated in [12j . that the notion of polynomial sup-interpretation 
strictly generalizes the notion of polynomial quasi-interpretation. In other 
words, every polynomial quasi-interpretation is a polynomial sup-interpreta- 
tion and there are programs which admit a sup-interpretation and no quasi- 
interpretation. As a consequence, sup-interpretation provides more inten- 
tionality than quasi-interpretation, i.e. it allows to capture the complexity 
of more algorithms. Such a flexibility is very interesting when we consider 
small complexity classes. For example, in [6], sup-interpretations allow to 
characterize all the functions bitwise computable in alternating logarithmic 
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time. Another interesting consequence develloped in [13J consists in an ap- 
plication of the sup-interpretation tool to termination criteria such as the 
dependency pairs [3] or the size change principle [TT] . 

The notion of quasi-interpretation has already been extended to Byte- 
code verification and to reactive programs. See for example [H EJ [7]. Con- 
sequently, a major issue consists in the adaptation of the sup-interpretation 
analysis to imperative and object-oriented programs. We try to tackle this 
problem in this paper by enlarging the framework of sup-interpretations to 
a fragment of object-oriented programs without recursion. Our language 
is very similar to the language studied in [9]. However, since we consider 
assignments, it is closer to a fragment of [8] where we add loop and while 
constructs. A consequence is that we have to control side effects. Our work 
is inspired by recent studies on the Implicit Computational Complexity of 
imperative programs [14, 10J. Contrarily to these seminal works, we work 
on polynomial algebra instead of matrix algebra. There are at least two rea- 
sons for such an approach. Firstly, the use of polynomials gives a clearest 
intuition and pushes aside a lot of technicalities. Secondly, polynomials give 
more flexibility in order to deal with method calls. 

The paper is organized as follows. After introducing our language and 
the notion of sup- interpretation of an object-oriented program, we give a cri- 
terion, called brotherly criterion, which ensures that each brotherly program 
computes objects whose size is polynomially bounded by the inputs sizes, 
even if the program is defined with function calls. To our knowledge, previ- 
ous works on the implicit computational complexity of imperative programs 
did not support such a flexibility. Consequently, this criteria seems to be a 
great improvement on the study of the complexity of imperative programs. 

2 Object-oriented Programs 
2.1 Syntax of programs 

We consider object-oriented programs. Basically a program is composed by 
three sets of disjoint symbols X, V and T and a set Class C T. The set 
X represents the set of attributes. Throughout the following paper, we use 
capital letters X, Y, Z, . . . for attributes. The set V is the set of parameters 
which are passed as arguments of a method. The symbols of Class are the 
class identifiers. They provide distinct data encodings such as the unary 
encoding, using the identifier S for a class having one attribute and the 
identifier e for a class without any attribute, or the binary encoding, using 
the class identifiers 1 and 0. Each function symbol f € T must be defined 
by one method of some class. A class C € Class is composed by attribute 
and method declarations, including a particular constructor method, which 
are described by the following grammar: 
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Attributes 3 A 
Expressions 3 e 
Commands 3 Cm 



= var X; \ var X; A 
= x | X X.f(e\, ■ ■ ■ , e n ) | new C(e±, ■ ■ ■ , 
= skip | X := e | Cmi;Cm2 | loop X {Cm} 
if e then Cmi else C1112 | while e {Cm} 
= f (x±, x n ) {Cm ; return X;} 
= Class C {A ; Cons ; M x ; . . . ; M n ; } 
= Class main{^4 ; Cm} 



) 



Methods 
Class 



3 M 
3 C 



main 



where X G X, x, x\ , ■ ■ ■ , x n E V, f G J 7 , ei , • • • , e n € Expressions and 
Mi; . . . ; M n £ Methods. The method Cons is a special constructor method 
of the shape C(xi, x n ) {X\ := x\\ . . . ; X n := x n } which appears in each 
class C £ Class whenever the class C has n attributes X\,--- ,X n . As a 
consequence, we have Class C J 7 . This particular method can only be used 
in a command of the shape X := new C(e±, ■ ■ ■ ,e n ). All attributes appearing 
in the methods of a given class Class must belong to the attributes of this 
class. Finally, we define the main class main to be a special class defined by 
attributes declarations and commands. 

We suppose that the attributes and methods of two distinct classes are 
pairwise distinct. 

For notational convenience, we sometimes refer to e as a sequence of 
expressions e±, ■ ■ ■ ,e n , whenever n is clear from the context. 

Given a program p, we define a precedence >jr on function symbols of J 7 . 
Set f >jf g if the method defining f is of the shape f (x) {Cm ; return X; } 
and the function symbol g appears in Cm. Take the reflexive and transitive 
closure of >j?, that we also note >f. It is not difficult to establish that >jr is 
a preorder. Lastly, we say that f >jr g if f >jf g and g >jf f does not hold. 
Intuitively, f >jr g means that f cannot call g. Throughout the following 
paper, we suppose that for each method of the shape f (x) {Cm ; return X; } 
and for each function symbol g which occurs in Cm, f >jr g, i.e. there is no 
recursive call in the program. 

For each expression e of a program, we suppose that function symbols 
f G T — Class appear only in the outermost position of an expression e. 
This restriction allows to deal with side effects in a clearest fashion. This is 
not a severe restriction since every program can be transformed efficiently 
in an equivalent program which does fit this requirement, by adding new 
attributes for the intermediate computations. For example, a command of 
the shape X := V.f(U.g(X)) is transformed into Y := U.g(X);X := V.f(Y) 
with Y a fresh attribute. For simplicity, we suppose, that no function symbol 
appears in the expression e of the commands if e then Cmi else C1112 and 
while e{Cm}. 

The attribute X is not allowed to occur in the command Cm of an iteration 
of the shape loop X {Cm}. The attribute X is not allowed to occur in 
a method of the shape f(a?) {Cm' ; return Y;}, if the function symbol f 
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appears in the command Cm of an iteration loop X{Cm}. In other words, 
the program is not allowed to read and to write the attribute X during the 
execution of a loop X {Cm}. 

Example 2.1: Here is an example of a program of our language: 

Class Position { 

var X; var Y; 

Position(x, y) {X := x; Y := y;} 

move(x, y) {X := A.add(x); Y := Y.add(y) ; return X; } 
getX() {skip ; return X; } 

} 

Class main { 

var W; var U; var V; Var Z; 
Cmi : V := new Position(W, U); 
Cm 2 : Z := V.aove(W,W); 
Cm 3 : U := V.getX(); 

} 

where Cmi , ■ ■ ■ , Cm3 are labels used to refer to commands and add is a method 
which is not described in the program and which corresponds to the unary 
or binary addition depending on the kind of defined objects. 

2.2 Semantics 

The domain of computation is the set of objects defined inductively by: 

Objects 3 v ::= b \ b(v\, ■ ■ ■ , v n ) b E Class 

Given a main class having n attributes X\, • • • , X n , an object Vi is stored in 
each Xi at any time. 

A ground substitution a represents a store which consists in a total 
mapping from X to objects in Objects. Given a ground substitution a and 
an attribute X, the notation a {X := u} means that the object stored in 
Xa is updated to the object u in a. A parameter substitution is a total 
mapping from V to objects in Objects. Given an expression e and a ground 
substitution a, we use the notation (e, a) — ► (u, a') whether the expression 
e evaluates to u and the store a is updated to a' . We use the notation 
(Cm, <r) — ► (a'), if a is updated to a' during the execution of the command 
Cm. Given a program p of main class Class main {^4; Cm} and a store a, p 
computes a store a' defined by (Cm, a) — > (a'}. 

The operational semantics of our language is inspired by the operational 
semantics of the java fragment given in [8] and is described in Figure HJ 
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o e x uv 

(o, a) -> (ocr, a) 

(e, cr) -> (u, a) f(x) {Cm ; return Y; } 3/3, x/3 = u (Cm/3, cr) -> (a') 

(Xf(e),<r) 
(e, a) -> (u, cr) 



C G Class 



(new C(e),a) -> (C(«),<r) 
(e,cr) -> (n,cr') 
(X Z e )^ (fT{ X:= U }) 



(skip, a) -> (cr) 
(Cmi, a) (a') <Cm 2 ,(7 / > -► (a") 
(Cmi;Cm 2 ,cj) -► (a") 
(e, a) -> (1, a) , (0, cr) or (u, a) 



with u > 1 



(if e then Cmi else Cm2, a) — > (Cmi, cr) , (Cm2, cr) or (skip, a) 

with Cm n = Cm; Cm n_1 and Cm = skip 



• with u ^ 1 



(loop Xi {Cm}, cr) -» ^Cml v *l,o-^ 

(e, Cr) -» (1, a) Or (1, a) 

(while e {Cm} , a) — > (Cm; while X {Cm} , cr) or (skip, cr) 



Figure 1: Call- by- value semantics 

If f is denned by a method of the shape f (x) {Cm ; return Y; }, then the 
evaluation of X.f(u) is performed by first evaluating the body Cm/3, with (3 
a parameter substitution such that x(3 = u, in the context of the object X 
and then returning the value stored in the attribute Y of the object X. 

The command skip does nothing. The command X := e assigns the 
value of e to the attribute X. The command X := new C(ei, • • • , e n ) first 
evaluates the expressions e±, ■ ■ ■ ,e n to the objects v\, ■ ■ ■ ,v n , then, it cre- 
ates a new object of the class C by assigning the value C(vi, ■ ■ ■ ,v n ) to the 
attribute X. The execution of Cmi; Cm 2 corresponds to the sequential execu- 
tion of Cmi an d Cm 2 . if b then Cmi else Cm 2 executes the command Cmi, 
Cm 2 or skip depending on whether the expression b is respectively evaluated 
to an encoding of 1, or another natural number. The size \v\ of a value v 
is defined to be the number of symbols of strictly positive arity in v. The 
command loop X {Cm} executes \v\ times the command Cm if v is the value 
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stored in X, i.e. Xa = v. Finally the command while b {Cm} is evaluated to 
Cm; while b {Cm} if b is evaluated to an encoding of 1 and to skip otherwise. 

Example 2.2: Consider the program of Example 12. 1L For each objects 
u, v, w, z such that a = {U := u, V := v, W := w, Z := z}, we have: 

(new Position(W, U), a) — » (Position^, u), a) 

{V := new Position(W, U),a) —> (a {V := Position(t(;, it)}) 

Moreover if v = Position(w, u) then: 

(V.getX(),<r) (w,a) 

(U :=V.getX(),a) -» (a{C/:=^}} 

3 Sup-interpretations and weights 
3.1 Assignments 

Definition 3.1: Given a class C having n attributes X\, ■ ■ ■ , X n , the assign- 
ment / of the class C is a mapping of domain dom(/) C T which assigns a 
function /(f) : (]R + ) m+1 i — > R + to every symbol f £ J- Class of arity m, 
which corresponds to a method of the class C, and which assigns a function 
/(C) : (M+) n i — > R+ to the constructor method of C. 

Given a program p, the assignment / of p consists in the union of the 
assignments of each class C of Class. 

A program assignment / is defined over an expression e if each symbol 
of T in e belongs to dom(J). Suppose that the assignment / is defined over 
an expression e, The partial assignment of e w.r.t. /, that we note J*(e) is 
the canonical extension of the assignment / defined as follows: 

1. If o is in X U V, then I*(o) = o 

2. If e is a sequence of expressions e\, ■ ■ ■ , e^, = I* (fix), ■ ■ ■ , I*(ek)- 

3. If C is a symbol in Class of arity m and e%, ■ ■ ■ ,e m are expressions, 
then, we have: 

/*(new C(ei,-- - , e m )) = J(C)(J*(ei), . . . , I*(e m )) 

4. If f £ T — Class is a symbol of arity m and ei, • • • ,e m are expressions, 
then, we have: 



r(Xf( ei ,-- - ,e m )) =/(f)(r( ei ),...,/*(e m ),X) 
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Notice that the assignment I*(e) of an expression e with m parame- 
ters x occurring in a class C having n attributes denotes a function from 
(R+) n+m -» M+. Consequently, we use the notation I*(e)(X lr -- ,X n ,x) 
when we apply such a function. 

Definition 3.2: Let Max- Poly {R + } be the set of functions defined to 
be constant functions in M + , projections, max, +, x and closed by composi- 
tion. Given a class with n attributes, an assignment I is said to be polyno- 
mial if for every symbol b of dom(I), 1(b) is a function of Max-Poly 

Definition 3.3: The assignment of a class symbol C € Class of arity 
m > is additive if 

rn 

J(C)(ox, • • • , o m ) = ^2 Oj + a c where a c > 1 
i=i 

If the assignment of each class symbol of strictly positive arity is additive 
then the assignment is additive. 

Definition 3.4: The size of an expression e is noted |e| and defined 
by |e| = if e is a 0-ary symbol and \b(ei, . . . , e m )\ = 1 + Yli \ e i\ if e = 
6(ei, . . . , e m ) with m > 0. 

Lemma 3.1: Given a program p having an additive assignment /, there 
is a constant a such that for each object v G Objects, the following inequal- 
ity is satisfied: 

\v\ < I*(v) < a x \v\ 

Proof: Define a = max cg c(/3 c ) where /3 C is taken to be the constant a c of 
definition 13.11 if c is of strictly positive arity and j3 c is equal to the constant 
I*(c) otherwise. The inequalities follow directly by induction on the size of 
a value. 

3.2 Sup-interpretations 

Definition 3.5: Given a program p of main class having n attributes 
Xi,..., X n , a sup- interpretation is an additive assignment 6 of p which 
satisfies: 

1. The assignment 9 is weakly monotonic. That is, for each symbol b € 
dom(#), the function 9(b) satisfies: 

Vi, o t >4^9(b)(...,o u ...)>9(b)(...,o' t ,...) 

2. For each function symbol f € dom((9) — Class of arity m, for each m 
tuple of objects v, and for each store a if pQ.f (v), a) — > {v,a') then 



^(f)^*^),^^)) > max(e*(v),e*(X i a')) 
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Intuitively, the sup-interpretation is a special interpretation of a symbol. 
Instead of yielding the symbol denotation, a sup-interpretation of a function 
symbol provides an upper bound on the outputs sizes of the function denoted 
by the symbol. It is worth noticing that sup-interpretation is a complexity 
measure in the sense of Blum [4] . 

Example 3.3: Suppose that the method add of Example 12.11 is defined 
over an encoding of unary numbers using two class constructor symbols S 
and e of respective arity 1 and 0. It admits the following additive and polyno- 
mial sup-interpretation 0(add)(oi, o 2 ) = <>i+<>2, 0(S)(o) = 0+1 and 0(e) = 0. 
Indeed, this function is monotonic. For every unary number S^e), we let the 
reader check that 9*(S v (e)) = (S^e)! = v. Moreover, for every unary number 
S v (e) and for every store a such that Xa = S u (e), with S" +1 (e) = S(S n (e)) 
and S°(e) = e, if (Xadd(S 1 '(e)), a) -» (S v+U (e), a {X := S v+U (e)}), then: 

0*(add)(0*(S ,, (e)),0*(S 11 (e))) = e*(S u (e)) + 6*(S v (e)) By Dfn of 9 

= u + v 6*{S v (e)) = v 
> max(u + v , u) 
= max(e*(S u+v (e)),d*(S u (e))) 

So that, Condition 2 of Definition 13.21 is checked. 

Lemma 3.2: Given a program p of main class having n attributes 
X\ , . . . , X n and having a sup-interpretation 9 defined over an expression 
e, then, for each parameter substitution (3, 9*(ef3) denotes a function from 
(R+) n to R + which satisfies: 

For each store <r, if (e/3, a) — > (v, a') then 

9*(eP)(9*(X 1 a),...,9*(X n a))>9*(v) 
Moreover, if e = Xi.f (ei, • • • , e n ), we have: 

9*(ep)(9*(X l a), 9*(X n a)) > 9*(X t a') 

Example 3.4: Consider the program of Example 12. 11 As demonstrated 
in Example[32J 0(add)(<>i, o 2 ) = Oi+o 2 , 0(S)(o) = o+l and 0(e) = define a 
sup-interpretation for the method add. The method move admits the follow- 
ing sup-interpretation 0(move)(x, y,o) = x + y + o and 0(Position)(x, y) = 
x + y + 1. Indeed, 0(move) and 0(Position) are monotonic and, for each 
store a = {U := u, V := Position(S Ul (e), S" 2 (e)), W := S w (e),Z := z}, we 
have: 

(V.move(w,w),a) -> (S Ul+w (e), a {V := Position(S ni+w (e), S U2+u, (e))}> 
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Since 0*(S n (e)) = n = |S n (e)|, we have to check Condition 2 of Definition [3J2 

6*(V.move(Wa, Wa))(9*(u, Position(S Ml (e), S" 2 (e)), S w (e), z)) 
= 9 {move) (6* (W a), 9*{Wa), V){9*(u, Position(S Ul (e), S" 2 (e)), S w (e), z)) 
= 0(move)(r(^),r(^),r(Position(S Ul (e),S" 2 (e)))) 
= 9*{Wa) +9*(Wa) +9* (Position(S Ul (e),S M2 (e))) 
= 9* (S w (e)) + 0* (S w (e)) + Ul + u 2 + 1 
> max(j« + ui,2 x w + u\ + U2 + 1) 
= max(r(S" 1+u '(e)),r(Position(S" 1+w (e),S U2+w (e)))) 



3.3 Weights 

Now, we are going to define the notion of weight which allows to control the 
size of the objects held by the attributes during loop and while iterations. 
Basically, a weight is a partial mapping over commands. The weights depend 
strongly on the considered command, so that we have to make the distinction 
between commands. 

For that purpose, define the relation C over commands by Cmi C Cm 

• if there are Cm2 and C1113 such that Cm = Cm2 ; Cmi ; C1113 , 

• Cm = if e then C1112 else C1113 and Cmi E Cni2 or Cmi E C1113, 

• Cm = loop X {C1112} and Cmi E Cm2, 

• or Cm = while e{Cni2} and Cmi E Cm2, 

and its reflexive and transitive closure, that we also note C. C defines a 
partial ordering over commands. The strict relation C is defined by Cmi C Cm 
if Cmi E Cm and Cmi 7^ Cm 

Definition 3.6: A command Cm is said to be: 

• flat if there is no Cmi of the shape Cmi = while e{Cni2} or Cmi = 
loop X {C1112} such that Cm C C1112. 

• minimum if there are no commands Cmi and Cni2 and no expression e 
such that Cm = Cmi;Cm2 or Cm = if e then Cmi else C1112 

• whiled if there is a command Cmi = while e {C1112} such that Cm C Cmi 
or Cmi E Cm 

• looped if if there is a command Cmi = loop X {C1112} such that Cm C 
Cmi and the command C1112 is not whiled. 

Definition 3.7: Given a program p having a main class with n at- 
tributes, the weight of a command w is a partial mapping. It assigns to: 



4 CRITERIA TO CONTROL RESOURCES 



10 



• every flat, minimum and looped command Cm, a total function ujcm 
from (R+) n+1 to R+ 

• every flat, minimum and whiled command Cm, a total function ojcm 
from (R+) n to R+ 

which satisfy: 

1. ujcm is weakly monotonic Vz, Oj > =>- wcm(- • • , <>i, • • •) > ^Cm(- • •)<>$)•••) 

2. cj Cm has the subterm property Vi, Voj € M + wcm(- •-,<>«,•••) > <>i 
A weight u; is polynomial if each uo Cm is a function of Max- Poly 

4 Criteria to control resources 
4.1 Brotherly criterion 

The brotherly criterion gives constraints on weights and sup-interpretations 
in order to bound the size of the objects computed by the program by some 
polynomial in the size of the inputs. 

Definition 4.8: A program having a main class with n attributes 
Xi, ■ ■ ■ , X n is brotherly if there are a polynomial sup-interpretation and a 
polynomial weight such that: 

1. For every flat, minimum and looped command Cm of the main class, 
we have: 

- For every expression of the shape Xj.f(e±, • • • , e m ) occurring in Cm: 
wa.Cr+1, X ir --,X n )> u Cm (T, X u ..., Xj_ u 9* (e)(X), X j+1 , ...,X n ) 

- For every assignment Jj := e C Cm, we have: 

wcm(r+l, Xi, ■ ■ ■ , X n ) > wcm(r, X\, . . . , 6*(e)(X),Xi + i, . . . , X n ) 
with T is a fresh variable. 

2. For every flat, minimum and whiled command Cm of the main class, 
we have: 

- For every expression of the shape Xj.f (e±, • • • , e m ) occurring in Cm: 

vcm(Xi, • • • , X n ) > u>cm(Xi, . . . , Xj-i , 6 (e) (X) , Xj + i , . . . , X n ) 

- For every assignment Xi := e C Cm, we have: 

wcm(Ai, • • • , X„) > w Cm (Ai, . . . , 0*(e)(X),Xj + i, . . . , A n ) 
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Intuitively, the first condition ensures that the size of the objects held 
by the attributes remains polynomially bounded. The fresh variable T can 
be seen as a temporal factor which takes into account the number of iter- 
ations allowed in a loop. Such a number is polynomially bounded by the 
size of the objects held by the attributes. The second condition on whiled 
commands is very similar, however there is no more temporal factor, since 
we have no piece of information about the termination of a whiled command. 
Theorem 4.1: Given a brotherly program p of main class Class main {A; Cm} 
having n attributes X\ , • ■ • , X n , there exists a polynomial P such that for 
any store a if (Cm, a) — * {a') then 

P(\X 1 a\,...,\X n a\) > max(|AV|) 

1=1. .71 

Example 4.5: The program of example 12. H is brotherly since it admits a 
polynomial sup-interpretation 6 and it has no looped and whiled command. 
Example 4.6: Consider the following program, over unary numbers: 

Class main { 

var Xi; 
var X 2 ; 
var X 3 ; 
loop X\ { 

X 3 := X 3 .add(X 2 ); 

}; 

} 

Cm = loop X\ {X 3 := X3.add(X2)} is the only minimum, flat and looped 
command. Applying the brotherly criterion, we have to find a polynomial 
weight wcm and a polynomial sup- interpretation 6 such that: 

u Cm {T+l,X 1 ,X 2 ,X 3 ) > u Cm {T,X 1 ,X 2 ,e*{X 3 .a L dd(X 2 ))) 

with T is a fresh variable. 

Since 9 (add) (01,02) =01+02 is a sup-interpretation of the method add, 
previous inequality is satisfied by taking u>c m (T, <>i , 02, 03) = T x o 3 + 01 + o 2 
and the program is brotherly. 

References 

[1] R. Amadio, S. Coupet-Grimal, S. Dal-Zilio, and L. Jakubiec. A functional scenario for 
bytecode verification of resource bounds. In CSL, volume 3210 of LNCS, pages 265—279. 
Springer, 2004. 

[2] R. Amadio and S. Dal-Zilio. Resource control for synchronous cooperative threads. In 
Concur, pages 68-82, 2004. 



REFERENCES 



12 



[3] T. Arts and J. Giesl. Termination of term rewriting using dependency pairs. Theoretical 
Computer Science, 236:133-178, 2000. 

[4] M. Blum. A machine-independent theory of the complexity of recursive functions. Journal 
of the Association for Computing Machinery, 14:322-336, 1967. 

[5] G. Bonfante, J.-Y. Marion, and J.-Y. Moyen. Quasi-intcrprctation a way to control resources. 
Submitted to Theoretical Computer Science, 2005. 

[6] G. Bonfante, J.-Y. Marion, and R. Pechoux. A characterization of alternating log time by 
first order functional programs. In LPAR 2006, volume 4246 of LNAI, pages 90-104, 2006. 

[7] S. Dal-Zilio and R. Gascon. Resource bound certification for a tail-recursive virtual machine. 
In A PL AS 2005, volume 3780 of LNCS, pages 247-263. Springer- Verlag, 2005. 

[8] S. Drossopoulou and S. Eisenbach. Describing the semantics of Java and proving type sound- 
ness. Formal Syntax and Semantics of Java, pages 41-82, 1999. 

[9] A. Igarashi, B.C. Pierce, and P. Wadlcr. Featherweight Java: A Minimal Core Calculus for 
Java and GJ. ACM Transactions on Programming Languages and Systems, 23(3):396-450, 
2001. 

[10] L. Kristiansen and N.D. Jones. The flow of data and the complexity of algorithms. New 
Computational Paradigms, 3526:263-274. 

[11] C.S. Lee, N.D. Jones, and A.M. Ben-Amram. The size-change principle for program termi- 
nation. In Symposium on Principles of Programming Languages, volume 28, pages 81-92. 
ACM press, january 2001. 

[12] J.-Y. Marion and R. Pechoux. Sup-intcrprctations, a semantic method for static analysis of 
program resources. Submitted to TOCL. 

[13] J.-Y. Marion and R. Pechoux. Resource analysis by sup-interpretation. In FLOPS 2006, 
volume 3945 of LNCS, pages 163-176, 2006. 

[14] K.-H. Niggl and H. Wunderlich. Certifying polynomial time and linear /polynomial space for 
imperative programs. SIAM Journal on Computing. 



